Kickoff
Aligning the product strategy
The goal of this project is twofold. Firstly, we aim to build a matching product to enhance engagement between employer and job seeker and ultimately lead to more hires. Secondly, we aim to leverage this project as a pilot to build the HR platform with our Japan partners.
Since the product will affect multiple core touchpoints across Indeed, including the ATS (Application-tracking-system) dashboard, we talked to several product owners across teams to align on the common vision and approach. Here are the key takeaway
To build on the existing ATS which is already working, so it won't disrupt the experience of Japanese users.
To reuse the US matching product as much as possible to keep consistency, and only introduce new components when needed.
To design with scalability and compatibility on day one, since the platform will need to integrate with other products from our third-party alliances.



Research
Defining our japan users
Next, we need to define our target users. From the desktop research, we know that 99.5% of companies in Japan are small and medium-sized businesses (SMBs) and approximately 95% of them are companies with 1-29 employees.
These small businesses are usually restrained on resources. People who are responsible for hiring often lack the necessary knowledge, tools, and time to find the right talent. These self-serve users are our primary focus as they comprise most of our user base.
On the other hand, many of our existing paid users are hiring agencies who use Indeed to help larger companies post jobs or source candidates. Therefore, we also need to consider how to integrate this workflow.


Research
Test our assumptions through research
The previous research and user archetype helped us formulate the initial design assumptions. Firstly, we discovered that despite the familiarity with sourcing products and services, Japanese employers often find them indifferent, the recommended jobs or candidates tend to be too generic and do not align with their experience or requirements. Secondly, we learned that Japanese job seekers are cautious and require more information before applying, suggesting the need for further explanation of the new services.
With the US product on hand, we quickly implemented changes based on these assumptions, built prototypes, and tested them with our target users—both employers and job seekers. The result reveals several interesting finding that impacts the design down the line:
Many employers are expecting a place for them to input specific criteria/requirements before seeing the match result.
Employers want to know more information from the matched candidates such as age, full work history, location, and even personality
Employer shows strong interest in customization, they think it's more personal and can help the message stand out.
Job seekers appreciate ‘passive’ ways to find jobs. And they expect a higher chance to get hired if approached by an employer
High relevancy of the job and proper email frequency will be key for job seekers to use the service
Many job seekerscan not tell the company’s atmosphere and are not sure if the job will fit their personality.
Legal
Legal alignment and tradeoffs
One major challenge we faced in launching our matching product in Japan was complying with legal requirements. In Japan, Indeed holds a license as an information provider. This means we must present information neutrally without favoring or hiding anything from the users. This poses a problem as matching is inherently selective service.
So we collaborated with the PM and legal teams to explore alternatives that would satisfy policy requirements. Firstly, we show recommended candidates while offering a general search so employers can freely access the entire resume pool on Indeed. Secondly, we prioritized top results and preserved the long tail through pagination. And finally, we set some basic criteria to use the serivce, so employers and job seekers will get more relevant recommendations.
Although it took months to resolve, the legal battle helped us prioritize essential experience while maintaining Indeed's legitimacy in the local market.

Design
Design sprint: from vision to mvp
With these insights in mind, it's time to assemble the matching product and candidate platform. To ensure we maximize the outcome and minimize the impact with other initiatives, we brought together key stakeholders, including PMs, designers, and developers from immediate, Indeed, and third-party teams. We host a four-day hybrid design sprint, discussing the product vision, identifying opportunity areas, risk, and feasibility to define the roadmap and MVP plan.
The productive session yielded vision alignment and end-to-end MVP flows. Additionally, we highlighted some key technical assumptions for all parties to explore further, such as the possibility of a common data format and APIs for building the matching and searching functions.



Testing
User testing: The full ATS experience
While we are building the matching service, a parallel team is also planning an initiative to facilitate engagement between employers and job seekers through lightweight connections such as messages or calls.
To ensure both projects will coexist well on the ATS platform, I worked with the lead designer to lay out the end-to-end applicant tracking journey and built a prototype to test with our Japanese employers.
The results show a positive sign: Employers appreciate seeing both matched and connected candidates on the ATS dashboard, allowing them to reach out when they need more applicants. However, many find it confusing to see the candidates together with those who already applied for the job. These insights, along with a few others, provide us with a clear direction on how to iterate the design to fulfill their day-to-day hiring tasks.
Implementation
Launch with a platform-first mindset
The move to being a platform-based product raises several questions and challenges in UX. For example, which protocols and design standards should we follow? What should be configurable and what should be tailor-made to fulfill unique local needs? How should we communicate the value of using this new feature beyond Indeed our UI and policies? The bottom line is that we can fulfill all use cases while remaining flexible to adapt and change the matching product over time.
As the lead designer, I spent most of my time working with internal and external teams to address these questions - walking through the user journey, highlighting risks, common patterns, policy gaps, and data formats such as APIs and matching algorithms. Through countless sessions, we are able to identify shared resources, priorities, and a roadmap to ensure we move forward with maximum alignment and compatibility.
